\section{Prometheus design}
The long term objective of our multi-agent system is to create a believable and
entertaining artificial opponent. To that end we use the Prometheus methodology
to create our MAS design. Creating a fully functional MAS system for a Real Time
Strategy is daunting task that can not be accomplished at once. Our approach in
the design of our system is to draw the big picture of our agent architecture
and go into the details for implementing a simple use case.

\subsection{Applying the methodology}
We've tried to follow the Prometheus methodology as closely as possible. We have
started with the overall vision and after that we have begun to nail down the
details only on those aspects of the design that are close to the scenario we
want to implement. What does this means? It means that for instance all high
level description of the agents appear in the generated artifacts but not the
low-level ones of the agents that are not directly involved. For instance, you
can see a description of the \emph{Communication Agent} but not its plans or
capabilities since it is not involved in the scenario \emph{Search for the Enemy
Commander}. All the generated artifacts can be read in 
\autoref{app:sysSpec}, \autoref{app:archDesign} and \autoref{app:detDesign}.


\subsection{Goal Specification \& refining}
The system design began with the writing of the \textbf{System's Objectives}.
They were:
\begin{quotation}
We want a system able to play the game of SpringRTS. It will be able to control the
Commander to create buildings. Some of those buildings in turn will be able to create a
limited set of units that will be used to attack the enemy player. We need to
gather resources to build more units or buildings. We also want 
to implement communication between team members.	
\end{quotation}

This in turn gave rise to the following Goals:
\begin{quotation}
	\noindent
	\begin{verbatim}
	* Control the commander
		- Move unit
		MOVEMENT
	
	* Create Buildings
		- Collect raw materials
		- Construct the building
		CONSTRUCTION
	
	* Create Units
		- Construct the building for units
		- Issue the order of creating unit
		CONSTRUCTION
	
	* Attack
		- Attack unit (from Control the commander)
		- Create a squad
		ATTACKING
	
	* Defend
		- Defend building
		- Defend unit
		ATTACKING
	
	* Send message to teammate
		- Ask for help defending
		- Ask for help attacking
		COMMUNICATION	
		\end{verbatim}
\end{quotation}

This is the final product of the goal refinement. First we started with the main
goals marked with the ``*''. Those goals in turn were refined to finer subgoals
marked with the symbol ``-''. In the initial stages most of the subgoals were
duplicated in the main goals. The Prometheus methodology instructs that those
goals must be grouped with those they are similar enough. After this pass we
identified the main Functionalities our system has to provide, and they were
given a name (capitalized words) expressing a common treat among all the goals.

\subsection{Scenarios \& Functionalities}
We have seen how 5 basic functionalities arose from the goal specification and
refinement. They can be roughly categorized in 3 groups, unit management,
construction and communication, but we think that this refinement is not
necessary given the low number of goals. They are developed in
\autoref{sec:functionalities}.

To fix concepts and interactions, Prometheus recommends to create some
\textbf{Scenarios} where a given functionality can be seen as the interaction
between the different goals in the MAS. Given the complexity of a Real Time
Strategy System we have concentrated our design mainly on the scenario
\emph{Search for the Enemy Commander}. This scenario tries to erase the
unknowing of the Enemy Commander position and orchestrates all the needed
actions.

\subsection{Agent Types}
Following the Prometheus methodology we create agent types and functionalities.
We can see that the MOVEMENT functionality is something we might need on
military and economic units. We had here our first design decision, to duplicate
the functionality on two different agents or to group that functionality on a
single agent. Our solution was to group that functionality on a specialised
agent because that way we have low coupling in the movement functionality, we
could in the future replace the path-finding and group coordination routines
without major disturb to the whole system. The chosen agent types and
acquaintances can be seen in \autoref{fig:Agents}.

\begin{figure}[htp]
	\begin{center}
		\includegraphics[width=7cm]{images/Agents.png}
	\end{center}
	\caption{System agents}
	\label{fig:Agents}
\end{figure}

In brief:
\begin{itemize}
	\item The \textbf{General} is the coordinator in this hierarchical setup. It
		has the high level objectives in mind and orchestrates the other agents
		accordingly.
	\item The \textbf{Military} is the agent responsible of managing the
		military units. He has the knowledge about tactics, unit weakness and
		the like.
	\item The \textbf{Econ} is the agent responsible of the construction of
		units and buildings. It has knowledge about the tech tree, the resources
		necessary to build units and these all knowledge.
	\item The \textbf{Movement} agent is an agent specialised on moving units
		across the map. It has knowledge about the different terrains, has
		path-finding algorithms and can coordinate squad movements.
	\item The \textbf{Communications} agent coordinates all the messages
		exchanged with teammates in case that our system is playing a
		cooperative game. It knows who to talk to and keeps a detailed log of
		past communications.
\end{itemize}

\subsection{Messages \& Protocols}
Since we are implementing a scenario in which several agents has to coordinate
to reach a high level Goal, we have to define some protocols and messages. Our
scenario starts when the General acknowledges that he has no information about
what is the position of the Enemy Commander. He then issues the order to the
Econ Agent to build more units to perform a reconnaissance tasks.  The Econ
Agent acknowledges when those units have been created. At that point the General
transfers responsibility to the Military Agent and it issues the order to
explore the map in order to find the Enemy Commander. All those messages and
protocols can be seen in \autoref{sec:Protocols}.


\subsection{Capabilities \& Processes}
This part of the Prometheus methodology is the less developed one. To keep the
workload manageable we intentionally have kept the design document as simple as
possible without losing too much detail. It is because of that that this section
can only be outlined. The capabilities are finer segmentations of the previously identified
functionalities.

All in all, we can outline which capabilities could arise if the system is
developed further. We have talked about the different kinds of movements that
can be performed, so Movement related capabilities could be path-finding,
formation movement, timing and coordination, etc. On the military agent,
capabilities could be developed as to refine the abstract attack and defense
concepts to situations like ambush, defend (attack) a specific unit, etc. We
though that this level of detail was beyond the scope of this work.

As for the Processes, we identified the one that coordinates the Econ and
Military Agent by the General. It involves several protocols and basically is
the orchestration of this communication to remove the belief of the General of
not knowing where is the Enemy Commander.


